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Abstract 

Much effort is spent everyday by programmers in trying to reduce 
long, failing execution traces to the cause of the error. We present a 
new algorithm for error cause localization based on a reduction to 
the maximal satisfiability problem (MAX-SAT), which asks what 
is the maximum number of clauses of a Boolean formula that can 
be simultaneously satisfied by an assignment. At an intuitive level, 
our algorithm takes as input a program and a failing test, and com- 
prises the following three steps. First, using symbolic execution, we 
encode a trace of a program as a Boolean trace formula which is 
satisfiable iff the trace is feasible. Second, for a failing program ex- 
ecution (e.g., one that violates an assertion or a post-condition), we 
construct an unsatisfiable formula by taking the trace formula and 
additionally asserting that the input is the failing test and that the 
assertion condition does hold at the end. Third, using MAX-SAT, 
we find a maximal set of clauses in this formula that can be satisfied 
together, and output the complement set as a potential cause of the 
error. 

We have implemented our algorithm in a tool called BugAssist 
for C programs. We demonstrate the surprising effectiveness of 
BugAssist on a set of benchmark examples with injected faults, 
and show that in most cases, BugAssist can quickly and precisely 
isolate the exact few lines of code whose change eliminates the 
error. We also demonstrate how our algorithm can be modified to 
automatically suggest fixes for common classes of errors such as 
off-by-one. 

1. Introduction 

A large part of the development cycle is spent in debugging, where 
the programmer looks at a long, failing, trace and tries to localize 
the problem to a few lines of source code that elucidate the cause 
of the problem. We describe a novel algorithm fox fault localization 
for software. The input to our algorithm is a program, a correctness 
specification (either a post-condition, an assertion, or a "golden out- 
put"), and a program input and corresponding execution (called the 
failing execution) that demonstrates the violation of the specifica- 
tion. The output is a minimal set of program statements such that 
there exists a way to replace these statements such that the failing 
execution is infeasible. 
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Internally, our algorithm uses symbolic analysis of software 
based on Boolean satisfiability, and reduces the problem to maxi- 
mum Boolean satisfiability. It takes as input a program and a failing 
test case and performs the following three steps. First, it constructs 
a symbolic trace formula for the program path executed by the test 
input. This is a Boolean formula in conjunctive normal form such 
that the formula is satisfiable iff the program execution is feasi- 
ble (and every satisfiable assignment to the formula correspond to 
the sequence of states in a program execution). The trace formula 
construction proceeds identically to symbolic execution or bounded 
model checking algorithms t2ll6l llll[T6l . 

Second, it extends the trace formula by conjoining it with con- 
straints that ensure the initial state satisfies the values of the failing 
test and the final states satisfy the program post-condition that was 
failed by the test. The extended trace formula essentially states that 
starting from the test input and executing the program trace leads to 
a state satisfying the post-condition. Obviously, the extended trace 
formula for a failing execution must be unsatisfiable. 

Third, it feeds the extended trace formula to a maximum satisfi- 
ability solver. Maximum satisfiability (MAX-SAT) is the problem 
of determining the maximum number of clauses of a given Boolean 
formula that can be satisfied by any given assignment. Our tool 
computes a maximal set of clauses of the extended trace formula 
that can be satisfied, and take the complement of this set as a candi- 
date set of clauses that can be changed to make the entire formula 
satisfiable. Since each clause in the extended trace formula can be 
mapped back to a statement in the code, this identifies a candidate 
localization of the error in terms of program statements. Note that 
there may be several minimal sets of clauses that can be found in 
this way, and we enumerate each minimal set as candidate local- 
izations for the user. In our experiments, we have found that the 
number of minimal sets enumerated in this way remains small. 

More precisely, our algorithm uses a solver for partial MAX- 
SAT. In partial MAX-SAT, the input clauses can be marked hard 
or soft, and the MAX-SAT instance finds the maximum number of 
soft clauses that can be satisfied by an assignment which satisfies 
every hard clause. In our algorithm, we mark the input constraints 
(that ensure that the input is a failing test) as well as the post- 
condition are hard. This is necessary: otherwise, the MAX-SAT 
algorithm can trivially return that changing an input or changing 
the post-condition can eliminate the failing execution. In addition, 
in our implementation, we group clauses arising out of the same 
program statement together, and keep the resulting MAX-SAT in- 
stance small. 

We have implemented our algorithm in a tool called BugAssist 
for fault localization of C programsrl BugAssist takes as input 
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a C program with an assertion, and a set of failing test cases, 
and returns a set of program instructions whose replacement can 
remove the failures. It builds on the CBMC bounded model checker 
for construction of the trace formula and an off-the-shelf MAX- 
SAT solver 1211 to compute the maximal set of satisfied clauses. 
We demonstrate the effectiveness of BugAssist on 5 programs from 
Siemens set of benchmarks with injected faults [8]. The TCAS 
program in the testsuite is run with all the faulty versions in detail 
to illustrate the completness of the tool. In each case, we show that 
BugAssist can efficiently and precisely determine the exact (to the 
human) lines of code that form the "bug". The other 4 programs 
are used to show the scalability of the tool by using error trace 
reduction methods for real world programs. 

We can extend our algorithm to suggest fixes for bugs automat- 
ically, by noticing that the MAX-SAT instance can be used not 
only to localize problems, but also to suggest alternate inputs that 
will eliminate the current failure. In general, this is an instance of 
Boolean program synthesis, and the cost of the search can be pro- 
hibitive. However, we have experimentally validated that automatic 
suggestions for fixes is efficient when we additionally restrict the 
search to common classes of programmer errors, such as replace- 
ment of comparison operators (e.g., < by <) or off-by-one arith- 
metic errors. For these classes of systems, BugAssist can automat- 
ically create suggestions for program changes that eliminate the 
current failure. 

Error localization is an important step in debugging, and im- 
proved automation for error localization can significantly speed-up 
manual debugging and significantly improve the usability of auto- 
matic error-detection tools (such as model checkers and concolic 
testers). Based on our implementation and experimental results, we 
feel BugAssist is a simple yet precise technique for error localiza- 
tion that effectively leverages efficient SAT solving techniques for 
error detection and applies them to error localization. 

Related Work. Fault localization for counterexample traces has 
been an active area of research in recent years 1 1 , 12 -14 231 1241 . 
Most papers perform localization based on multiple program runs, 
both successful and failing, and defining a heuristic metric on 
program traces to identify locations which separate failing runs 
from successful ones. 

Griesmayer et al.| 12| gives a fault localization algorithm for C 
programs by constructing a modified system that allows a given 
number of expressions to be changed arbitrarily and using the 
counter example trace from a Model Checker. This requires in- 
strumenting each expression ej in the program with (diag == 
i?nondet() : ej), where diag is a non deterministic variable and 
nondet() is a new variable with the size equal to that of d. The 
number of diagnosis variables is equal to the number of compo- 
nents that are faulty in the program and need to be analyzed before 
creating the modified system. So each expression in the program 
requires a new variable in the modified system along with the di- 
agnosis variables which could blow up the size of the instrumented 
program under consideration. In this work we avoid these draw- 
backs using selector variables and efficient MAX-SAT instance for- 
mulation using clause grouping technique. 

Many existing work 1 14 24, 32] on fault localization uses the 
difference between faulty trace and a number of successful traces. 
The work of Ball at el. (T| use multiple calls to a model checker 
and compare the counterexamples to a successful trace. The faults 
are those transitions that does not appear in a correct trace. Our 
approach does not require comparing the traces or a successful run 
of the program as benchmark. We report the exact locations where 
the bug could be corrected instead of a minimal code fragment or a 
fault neighbor location. 

An alternate approach to reduce the cognitive load of debugging 
is delta debugging [32], where multiple runs of the program are 



used to minimize the "relevant" portion of the input. We believe 
our technique is orthogonal to delta-debugging and its variants, and 
can be composed profitably. 

While we describe our algorithm in pure symbolic execution 
terms, our algorithm fits in very well with concolic execution 
(3][H1[26 1 , where symbolic constraints are generated while the con- 
crete test case is run. Our motivation for using CBMC was the easy 
integration with MAX-SAT solvers, but in our implementations, 
we performed some optimizations (such as using concrete values 
for external library calls in the trace formula and constant-folding 
input-independent parts of the constraints) similar to concolic exe- 
cution. 

The motivation to use unsatisfiability cores is their recent suc- 
cess in hardware circuit design debugging described in Safarpour 
et al. 1 5 25 1 . MAX-SAT based debugging is used as a framework 
for debugging gate level VLSI circuits. Unsatisfiability cores have 
also been used to pin point over-constrains in declarative models 
(27). 

2. Motivating Example 



Program 1 A simple example, 
int Array [3] ; 
int testme(int index) 
{ 



1 if ( index != 1) /* Potential Bug 2 */ 

2 index = 2 ; 

3 else 

4 index = index + 2; /* Potential Bug 1 */ 



5 i = index; 

6 return Array[i]; //assert(i >= kk i < 3) 
} 



We start with an informal description of BugAssist. Consider 
the function testme in Program[T]which returns a value at a new lo- 
cation from an array of size 3. The function takes in two arguments: 
the array itself and the current index value. The function does some 
computation on the current index value (shown in lines 1-4) to find 
the new index and returns the value at new index in line 6. The array 
dereference on line 5 generates implicit assertions about the array 
bounds shown in line 6. 

The program has a bug. If the input index is equal to 1, then the 
else-branch sets index to 3, and the subsequent array dereference 
on line 6 is out of bounds. Testing the program with this input 
will find the bug, and return a program trace that shows the array 
bounds violation at the end. But testing or model checking returns 
a full execution path, including details irrelevant to the specific bug, 
and do not give the reason for failure, or the cause of the bug. The 
localization algorithm in BugAssist helps to nail down the issue to 
a few potential bug locations in the program where the correction 
has to be made. 

BugAssist works as follows. Starting with the test input 
index = 1 and the corresponding program trace: 

assume(index = 1); index = index + 2; i = index; 

it first constructs a symbolic trace formula TF encoding the execu- 
tion trace: 

TF = indexi = 1 A index2 = indexi + 2 A i = index2 



We assume that integers and integer operations are encoded in a bit- 
precise way, and without loss of generality, the trace formula is a 
Boolean formula in conjunctive normal form. We omit the standard 
encoding from imperative programs to Boolean formulas (see, e.g., 
ID). 

Clearly, at the end of the trace, the assertion 
i < 3 

does not hold. Consider now the formula 

$ = indexi = 1 A Tf^ A i_<J> 

test input trace formula assertion 

which is unsatisfiable. Intuitively, the formula captures the run of 
the program starting with the error-inducing test input, and asserts 
that the assertion holds at the end (a contradiction, by choice of the 
input). 

We convert $ to conjunctive normal form (CNF) and feed it 
to a partial MAX-SAT solver (2TJ. A partial MAX-SAT solver 
takes as input a Boolean formula in CNF, where each clause is 
marked "hard" or "soft" and returns the maximum number of soft 
clauses (as well as a subset of clauses of maximum cardinality) 
that can be simultaneously satisfied by an assignment satisfying all 
the hard clauses. In case of $, we make the constraints coming 
from the test input (index = 1) and the assertion (i < 3) as 
hard, and leave the clauses in the trace formula soft. Intuitively, 
we ask, given that the input and the assertion are fixed, which 
parts of the trace formula are consistent with the input and the 
assertion? The partial MAX-SAT solver then tries to find a set of 
soft clauses of maximum cardinality which can be simultaneously 
satisfied while satisfying all the hard clauses. The Complement of 
a set of maximum satisfiability clauses (CoMSS) gives a set of 
soft clauses of minimum cardinality whose removal would make 
$ satisfiable, i.e., consistent with the view that the test input does 
not break the assertion. We use this set as potential locations of the 
program error. 

In addition, by grouping together clauses arising out of the same 
program statement, we can map the clauses back to the lines of the 
program. Using clause grouping, described in Section [3] each line 
in the program is mapped to a bunch of its soft clauses which are 
enabled and disabled simultaneously. 

In our example, the hard and soft clauses are: 

Hard :index = 1 A i < 3 
Soft :TF 

MAX-SAT returns that a possible CoMSS maps to the line 4 in the 
program. This is the unsatisfiable core whose removal or correction 
can satisfy the formula <£>. We claim that is a potential error location 
for the program and a fix would be to change the constant to any 
integer less than 2 and greater than -2. 

Suppose this is not where programmer wants to make a correc- 
tion and require other locations where he could fix the bug. We 
iterate by making another call to MAX-SAT, but this time make 
clauses arising out of line 4 hard, i.e., asking the MAX-SAT for 
possible CoMSS where line 4 is kept unchanged. This reveals an- 
other potential bug location in the code. We repeat this process un- 
til MAX-SAT gives the problem to be unsatisfiable and no more 
clauses can be removed to make this problem satisfiable. The error 
locations reported by BugAssist are underlined in Program [T] On 
a closer look, these are all the places where the correction can be 
made. Either changing the constant value at line 4 or the conditional 
statement at line 1 can fix the program. BugAssist is available as an 
Eclipse plug-in, making it easy for the programmer to interactively 
find potential error points. 

Notice that our technique is stronger than simply taking the 
backward slice of the program trace, and gives fine-grained infor- 



mation about potential error locations. The backward slice for this 
trace contains all the lines 1,4, and 5. Our algorithm returns lines 1 
and 4 separately as potential error locations. 

So far we have focused on error localization. The methodology 
can be modified to suggest program repairs as well. Intuitively, the 
fault localization returns a set of program commands that are likely 
to be wrong. One can then ask, what are potential replacements 
to these commands that fixes the error? In general, the space of 
potential replacements is large, and searching this space efficiently 
is a difficult problem of program synthesis 1281 1291 . Instead, we 
take a pragmatic approach and look for possible fixes for common 
programmer errors. 

Specifically, we demonstrate our idea by fixing "off by one" 
errors. In this example, the error occurs due to accessing an out 
of bound array element by one. When BugAssist comes back with 
line 4 as a potential bug location, we try to "fix" the bug by 
changing the constant whose new value is one off its current value. 
So we change the value 2 in this line to 3 or 1 and check if either 
of these values satisfy the properties. This involves modifying the 
trace formula appropriately and checking if the failing program 
execution becomes infeasible with either change. So in this case 
we create two programs with new constants at line 4 as follows. 

Program! : index = index + 3 x 
Program2 : index = index + 1 y/ 

The new value 1 ensures that the error path is infeasible, and this 
can be used as a suggestion for repair for the program. The same 
procedure can be used to check for operator errors like use of plus 
instead of minus, division instead of multiplication, performing as- 
signment instead of equality test, etc., which are common program- 
mer error patterns. 

3. Preliminaries 

3.1 Programs: Syntax and Semantics 

We describe our algorithm on a simple imperative language based 
on control-flow graphs. For simplicity of description, we omit fea- 
tures such as function calls or pointers. These are handled by our 
implementation. 

A program G = (X, C, £o,T) consists of a set X of Boolean- 
valued variables, a set £ of control locations, an initial location 
Its £ £ and a set T of transitions. Each transition r £ T is a tuple 
(£, p, £') where £ and £' are control locations and p is a constraint 
over free variables from X U X', where the variables from X' 
denote the values of the variables from X in the next state. 

For a constraint p, we sometimes write p(X, X') to denote that 
the free variables in p come from the set X U X' . 

Our notation is sufficient to express common imperative pro- 
grams (without function calls): the control flow structure of the 
program is captured by the graph of control locations, and oper- 
ations such as assignments x := e and assumes assume(p) cap- 
tured by constraints x' — e A /\ {y' — y \ y £ X \ {x}} and 
p A /\ {a;' = x | x £ X} respectively. 

A state of the program V is a mapping from variables in X 
to Booleans. We denote the set of all program states by v.X. A 
computation of the program is a sequence (mo, so)(mi, si) ... £ 
(C x v.X)*, where mo = £o is the initial location, and for each 
i £ {0, . . . , k — 1}, there is a transition (mi, pi, mi+i) £ T such 
that (si, Si+i) satisfies the constraint pi. 

An assertion p is a set of program states. A program violates an 
assertion p if there is some computation (mo, so) . . . {mk, Sfe) such 
that Sfe is not in p. Typically, assertions can be given as language- 
level correctness requirements (e.g., "no null pointer dereference"), 
as programmer-specified asserts in the code, or as post-conditions. 



3.2 Trace Formulas 

A trace a is a finite sequence 
(rno,po,mi), (m 1 ,pi,m 2 ), (m fe _i, p fe _i, m fe ) of tran- 
sitions in T such that mo = • The trace a is feasible if there 
exists a computation (mo, So) . . . {frik, Sfc) such that for each 
z £ {0, . . . , k — 1}, we have (sj, Si+i) satisfies pi. 

Given a trace a, we define the ?race formula TF(cr) as the 
conjunction 

fe-i 

/\ Pi {Xi,X i+ i) (1) 

i=0 

where X; is a copy of the variables in X for each i £ {0, . . . , k} 
and pi(Xi, Xi+i) denotes the constraint pi(X, X') with the vari- 
ables in X substituted by corresponding variables in Xi and the 
variables in X' substituted by corresponding variables in Xi+i. 
Note that TF(cr) is satisfiable iff the trace a is feasible. 

While we have described Boolean programs, a C program with 
finite-bitwidth data, e.g., 32-bit integers, can be converted into an 
equivalent Boolean program by separately tracking each bit of the 
state, and by interpreting fixed-width arithmetic and comparison 
operators as corresponding Boolean operations on each individual 
bit. We omit the (standard) details, see e.g., (61 1311 . 

3.3 Partial Maximum Satisfiability 

Given a Boolean formula in conjunctive normal form, the maxi- 
mum satisfiability (MAX-SAT) problem asks what is the maximum 
number of clauses that can be satisfied by any assignment [ 17 1. The 
MAX-SAT decision problem is NP-complete; note that a formula 
is satisfiable iff all its clauses can be satisfied by some assignment. 

The partial maximum satisfiability (pMAX-SAT) problem takes 
as input a Boolean formula $ in conjunctive normal form, and 
a marking of each clause of $ as hard or soft, and asks what is 
the maximum number of soft clauses which can be satisfied by 
an assignment to the variables which satisfies all hard clauses. 
Intuitively, each hard clause must be satisfied, and we look for the 
maximum number of soft clauses which may be satisfied under this 
constraint. 

Recent years have seen a tremendous improvement in engineer- 
ing efficient solvers for MAX-SAT and pMAX-SAT. The widely 
used algorithm for MaxSAT is based on branch-and-bound search 
1181 , supported by effective lower bounding and dedicated infer- 
ence techniques. Recently, unsatisfiability based MaxSAT solvers 
by iterated identification of unsatisfiable sub-formulas was pro- 
posed in 1101 . This approach consist of identifying unsatisfi- 
able sub-formulas and relaxing clauses in each unsatisfiable sub- 
formulas by associating a relaxation variable with each such clause. 
Cardinality constraints are used to constrain the number of relaxed 
clauses I251I2T1 . 

In addition to solving the decision problem, MAX-SAT solvers 
also give a set of clauses of maximum cardinality that can be simul- 
taneously satisfied. The complement of these maximum satisfiable 
subsets (MSS) are a set of clauses whose removal makes the in- 
stance satisfiable(CoMSS). Since the maximum satisfiability subset 
is maximal the complement of this set is minimal 1 19 1. 

In this work we make use of these CoMSS which refers to 
the clauses whose removal can make the system satisfiable. Since 
we represent a C program as a boolean satisfiability problem with 
constraints and properties, these coMSS are oracles for potential 
bug locations. 

3.4 Efficient Compilation to MAX-SAT 

A single transition can lead to multiple clauses in the conjunctive 
normal form of the trace formula. In this section we suggest a 
method to simplify the MAX-SAT problem by grouping together 
clauses arising out of a single source-code statement. We now give 



a simple way of grouping clauses arising out of the same program 
operation. 

For each transition r = (m, p, m') £ T, we introduce a new 
Boolean variable A T . Then, we augment each clause arising out 
of p with X T . For example, suppose (of V . . .) A (c? V . . .) is a 
conjunctive normal form representation of p, then the augmented 
representation is (^A p V c\ V . . .) A (^A p V cf V . . .). 

The augmentation with A p has the following effect. When A p 
is assigned true, the original clauses in the CNF representation 
of p must be satisfied, while when A p is assigned false, each 
augmented clause is already satisfied. This helps to enable and 
disable the clauses corresponding to each transition by setting and 
unsetting the A p variable respectively. The A-variables are called 
selector variables. 

We use a representation of trace formulas using selector vari- 
ables. Instead of Equation {T} for the trace formula, we use the 
form: 

fc-i 

f\ CNF(p l (X l ,X I+1 ),A Pi )A f\ A p (2) 

i=l (;P,-)ET 

v ' v ^ / 

TF 1 TF 2 

where CNF(p, A p ) denotes the augmented representation for the 
CNF for p, and we label the two parts of the formula TFi and TF2 
for later reference. Intuitively, clauses from TFi will be marked as 
hard clauses to the MAX-SAT solver, and clauses from TF2 will 
be marked soft. Thus, the MAX-SAT solver will explore the space 
of possible program statements whose replacement will cause the 
error to go away. 

Notice that we allocate a selector variable for each transition 
of the program, so the number of selector variables is bounded by 
the size of the program. However, in a trace, the same program 
transition may occur multiple times (e.g., on unrolling a loop), and 
there is a distinct clause for each of these occurrences all tagged 
with the same selector variable. 

We use the abstraction technique on transitions, which corre- 
spond to line numbers of code in our implementation, but it is also 
possible to group the clauses from modules and recursively narrow 
down the problem to a module, and then to a line. 

4. Algorithm 

We now describe the algorithm for BugAssist. There are two 
phases of the algorithm: first, generate a failing execution (and a 
test demonstrating a failing execution), and second, find a minimal 
set of transitions that can render the failing execution infeasible. 

4.1 Generating Traces 

In general, any method of generating a failing execution of a pro- 
gram can be used as a starting point of our algorithm. In our im- 
plementation, we use two approaches. In case the program comes 
with a testsuite, we generate failing executions from failed tests. 
In case there are no available tests, we use bounded model check- 
ing (2] ID to systematically explore program executions and look 
for potential assertion violations. If a failing execution is found, the 
bounded model checking procedure can generate a concrete initial 
state that leads to the assertion violation. 

4.2 The Localization Algorithm 

Algorifhm[T]shows the BugAssist localization algorithm. Line 1 
calls the procedure to generate failing executions for the assertion. 
If no failing executions are found, the procedure returns. Otherwise, 
we get a concrete test case test as well as a program trace a 
demonstrating the failure of the assertion. 

Using the test, the failing execution, and the assertion, we 
construct two formulas (lines 5,6). The formula &h consists of 



Algorithm 1 Localization Algorithm 
Input: Program V and assertion p 

Output: Either p holds for all executions or potential bug locations 
1: (test, a) = GenerateCounterexample(P, p) 
2: if a is "None" then 

3: return "No counterexample to p found" 
4: else 

5: $ff = [test] Ap A TFi (a) 

6: <&s = TF 2 (cr) 

7: while true do 

8: BugLoc = CoMSS($ H ,$ s ) 

9: if BugLoc = then 
10: return "No more suspects" 

11: else 

12: output "Potential bug at CoMSS BugLoc" 

13: P = \/{\i | A, € BugLoc} 

14: <E> S = ®s\P and & H = $h U /3 



three parts. The first part, [test], is a formula asserting that the 
initial state coincides with the test case that caused the failure. 
Formally, for a program state s, the constraint [s] is defined as 
f\\x = s(x) \ x £ X}. The second part is the assertion p. The 
third part is the first part TFi(cr) of the trace formula from Equa- 
tion l|2j. The formula <E>s is the second part TF2(<r) of the trace 
formula from Equation |2). 

Notice that $h A $s is unsatisfiable. (Intuitively, it says that if 
the program is run with the test input test, then at the end of the 
execution trace a, the assertion p holds.) 

In subsequent calls to pM AX-SAT, clauses in <&h are treated 
as hard clauses, and clauses in $s are treated as soft clauses. 
Intuitively, treating <I?s as soft clauses enables us to explore the 
effect of changing each subset of transitions to see if the failing 
transition can be made infeasible. 

The search for localizations is performed in the while loop of 
lines 7-14. During each iteration of the while loop, we call the 
pMAX-SAT solver and get a CoMSS for the current (<£ff,$s) 
pair. Each of these clauses returned by CoMSS gives potential bug 
locations in the code, and is output to the programmer. 

Whenever we report a potential bug, we add a hard blocking 
clause for the corresponding CoMSS, so that in subsequent it- 
erations, this CoMSS is not explored again as a potential cause 
of error. In many of our experiments, the CoMSS returns a sin- 
gle A p clause as the indicator of error. In general, it returns more 
than one selector variable which indicates that the program cannot 
be fixed by changing any one line but must be changed at mul- 
tiple locations. (This does happen in experiments.) Adding each 
of these A p variables as a new hard clause blocks the occurrence 
of these clauses in a different clause combination. To avoid this 
problem, we compute a blocking clause j3 (lines 13) and make the 
blocking clause hard. For example, suppose the coMSS returned 
BugLoc = Ai, A2, . . . , Afe. This means that the bug can be fixed 
by making simultaneous changes to these k locations. In the next 
iteration, we add a new hard clause (Ai V ... V At) which ensures 
that this particular CoMSS is not encountered again, but other com- 
binations of these locations are still allowed. 

4.3 Dealing with Multiple Locations 

The BugAssist returns multiple locations where a correction is pos- 
sible. The experimental results in section [6T| shows that the number 
of potential error locations returned is quite small and in most cases 
the exact bug location is reported using a single failing execution. 
However, for reliabilty and further refinement of bug locations, we 
use a ranking machanism for bug locations by running the BugAs- 
sist algorithm repeatedly with different failing program traces and 



ranking the bug locations based on their frequency of appearance 
in each of these runs. While using a model checker for counter ex- 
ample traces, it gets the variable assignment for a SAT formula it 
created for the program. By changing the order of variables in the 
SAT algorithm 1 7 1 or by doing a random restart of the solver we can 
efficiently get a new counter example trace for the same variables. 
Running BugAssist with these new value gives a another bunch of 
potential bug locations. Repeating this process and ranking the bug 
locations narrow down the search to a few lines in the program. 

5. Extensions 

We now describe two extensions to the basic algorithm. 
5.1 Extension 1: Automated Repair 

BugAssist can be used for automated repair of programs, as it boils 
down the problem to a few potential bug locations in the code. After 
analysing the problem lines, we get an idea of the kind of error that 
could have happened. For example, if there is a constant in the line 
we could try to synthesize a new constant which can fix the code 
1121 or if there is an operator, changing the operator might be a 
repair for the bug. We demonstrate this capability by fixing "Off- 
By-One" 1301 errors in the program. They are a common logical 
error involving discrete equivalent of a boundary condition. Usually 
programmer forgets that a sequence starts at zero rather than one 
(e.g. array indices in many languages like C, C++). It is also caused 
during boundary check conditions by using a < instead of < or 
viceversa. 

During the code parsing phase, we mark the lines which has 
constants in them. After running BugAssist on the code, it gives 
the potential correction locations and if that is a marked line we 
assign value to the constant in the code and ask if the new 

values can satisfy the properties. 

The repair procedure is given in Algorithm [2] In line 1 the 
LocalizationProcedure is called to get the potential bug locations. 
The function GetConst(i) checks if line i has a constant in it, if 
so it returns the value to k. We change the constant k at line i and 
creates two new programs V'\ and V'2 each with one off k. The 
lines 6 and 8 check if the new programs contain an error trace. If 
one of those return an empty counter example it is declared as a 
repair to the buggy version of V. 



Algorithm 2 The Off-By-One Repair Algorithm 

Input: Buggy Program V and assertion p 

Output: Either Fixed program or no Off-By-One error. 

1: BugLoc = LocalizationProcedureCP,p) 

2: for all Ai € BugLoc do 

3: if (k = GetConst{i)) then 

4: V[ = (V\k) U (k + 1) 

5: V'2 = (V\k) U - 1) 

6: if GenerateCounterExampleCPi,;?) = then 

7: return V[ 

8: if GenerateCounterExampleCP^P) = then 
9: return V' 2 

10: output "Off-By-One error not found" 



5.2 Extension 2: Debugging Loops 

The bugs in loop body can be burdensome to fix as they might be 
hidden in initial iterations and visible afterwards. The usual model 
checker methodology to verify properties is by loop unwinding 
which duplicates the loop body r\ times, where r\ is the unwinding 
limit. The programmer would be interested in knowing the iteration 
at which the assertion is violated to get a better idea about the cause 



of the error. We suggest a method to catch the potential iteration of 
the loop where the bug appeared first. 

This is achieved using clause grouping and assigning weights to 
the soft clauses in the pMAX-SAT instance. Each time a loop body 
is duplicated (till bound rf) we create a new selector variable. For 
example, for a transition r = (m, p, m') £ T in the while loop 
body, during K th unwinding we augment each clause arising out of 
p with A". We add these selector variables as soft clauses to the 
MAX-SAT instance as before, but assign a weight as follows 



V"=i Weight(X^) = a + 77 - « 



(3) 



where a is the default weight for soft clauses. This make sure that 
the clauses corresponding to the initial iterations of the loop gets a 
higher weightage. The weights assigned to the soft clauses in the 
pMAX-SAT is the penalty that has to be paid to falsify the clauses. 
The solver extracts the CoMSS in such a way that the least iteration 
clauses are picked first as they weigh more than the latter iterations 
variables. This helps to pin-point the initial iteration of the loop 
which can reproduce the failure. 

6. Experimental Results 
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1 int Inhibit_Climb O { 

2 return (Climb_Inhibit?Up_Sep+300:Up_Sep) ; 

3 /*return (Climb_Inhibit?Up_Sep+100:Up_Sep) ;*/ 

4 } 

5 int Non_Crossing_Climb() { 

6 upward_pref erred=Inhibit_ClimbO >Down_Sep; 

7 if (upward_pref erred) { 

8 result = ! (Own_Below_Threat O ) II 

(! (Down_Sep >= ALIMO)) ; } 

9 else{ 

10 result = (Cur_Vertical_Sep >= 100) 

&& (Up_Sep >= ALIMO) ; } 

11 return result; 

12 } 

13 int Non_Crossing_DescendO { 

14 upward_preferred=Inhibit_Climb ()>Dourn_Sep; 



17 
18 



19 

20 } 
21 
22 
23 
24 
25 



if (upward_pref erred) { 

result = Own_Below_Threat () && 

(Cur_Vertical_Sep >= 100) && 
(Dom_Sep >= ALIMO);} 

else{ 

result = ! (Qwn_Above_Threat O ) II 
((0wn_Above_ThreatO) ftft 
(Up_Sep >= ALIMO ) ) ; } 

return result; 



int alt_sep_test O { 

enabled = true; /^conditions omitted*/ 
alt_sep = UNRESOLVED; 
if (enabled) { 

need_upward_RA=Non_Crossing_Climb C) kk 
Dwn_Below_Threat O ; 
need_douinuiard_RA=Non_Crossing_Descend() 
&& Om_Above_Threat() ; 



if (need_upward_RA && need_downward_RA) 

alt.sep = UNRESOLVED; 
else if Cneed_upward_RA) 
alt_sep = UPWARD_RA ; 
else if Cneed_downward_RA) 
alt_sep = D0WNWARD_RA ; 

} 

return alt_sep; 



27 
28 
29 
30 
31 
32 
33 
34 

35 } 

36 int mainO {/*inputs omitted*/ 

37 assert (alt_sep_test() == D0WNWARD_RA) ; 

38 } 



Figure 1. Basic Flow Diagram. 

We demonstrate the capability of the tool in this section by 
showing the results from running few programs from the Siemens 
test suite |8|. The Siemens test suite is widely used in the litera- 
ture for bug localization study 1 12 24 1. In section [6T| we analyse 
a simple program TCAS task 1151 in depth and in section |6~2| we 
illustrate the scalability of our method using more complex exam- 
ples. 

Figure [T] gives an overview of the implementation of BugAs- 
sist. We used CBMC [6| as the model checker for generating fail- 
ing traces and test inputs. Tests can also be fed directly. CBMC 
is a Bounded Model Checker for ANSI-C and C++ programs. For 
solving the pMAX-SAT instances, we used the Maximum Satisfi- 
ability with UNsatisfiable COREs (MSUnCORE) tool |21), which 
can handle large and complex weighted partial MaxSAT problems. 
The off-by-one error fix was synthesized using the MiniSAT2 (9) 
SAT engine. All our experiments are preformed on an 3.16 GHz 
Intel Core 2 Duo CPU with 7.6 GB RAM. 

6.1 TCAS Experiments 

The TCAS task of the Siemens test suite constitutes an aircraft 
collision avoidance system. It consists of 173 lines of code. The 
authors have created 41 versions of the program by injecting one or 
more faults. Their goal was to introduce faults that were as realistic 
as possible, based on their experience with real programs. We refer 



Figure 2. A Sample TCAS code with declarations and several 
code fragments omitted. All bug locations identified are underlined, 
original code at line 3; mutation at line 2. 



to the versions as "vl" to "v41". The suite also contains 1600 test 
cases which are valid inputs for the program. 

We created the golden outputs for these 1600 test cases by 
running the original version of the program. Then for each of the 
faulty versions, we ran those 1600 test vectors and matched with the 
golden outputs to segregate the failing test cases. Since the program 
does not contain a specification, we use the failing test cases as 
counterexamples and the correct value as its specification. 

Table[T|shows the result of running BugAssist on TCAS Test- 
suite. BugAssist ran 1440 times over all versions and 1367 of 
these runs pin-pointed the exact bug location, which is 95% of 
the total runs. The "TC#" in the table is the number of failed test 
cases for each version. We ran BugAssist with each of these failing 
testcases as failing program executions and the golden output as the 
assertion to be satisfied. The column "Error#" shows the number 
of errors injected in to each version. Most versions have only 1 
error but some have 2 and 3 errors. "Detect^" is the number of 
runs of BugAssist which detected the correct (human- verified) bug 
location. "SizeReduc%" is the percentage reduction in the code 
size given by the tool to locate the bug, the ratio of bug locations 
returned by the tool to the total number of lines in the code. The 



Table 1. Results of running BugAssist on TCAS task of the Siemens Test Suite. 



Version 


1C# 


Error# 


Detect# 


Mze 


Run 


Error 




Version 


1C# 


Error# 


Detect# 


iMzevc 


Run 


Error 










TD .In ^» OJ 

Keaucyc 


Time 


Type 












Keuucvo 


Time 


Type 


vl 


i n 
132 


i 
1 


1 M 

132 


o t~ 
0.6 


n n 1 ^ 
0.016 


op 




V21 


1 

lo 


1 


1 £. 

lo 


o c 
0.6 


n i no 
0.1U8 


op 


v2 


69 


1 


69 


4.6 


0.068 


const 




v22 


11 


1 


11 


5.7 


0.056 


code 


V3 


23 


i 
1 


1 Q 

13 


9.0 


0.096 


op 




V23 


A O 

42 


1 


A 1 
41 


0.3 


n i nn 
0.100 


code 


v4 


26 


1 


26 


9.2 


0.104 


op 




v24 


7 


' 


7 


8.6 


0.092 


op 


. ,c 
VJ 


i n 
10 


i 
1 


i n 
10 


O A 

0.6 


n 1 on 
0.120 


assign 




V2j 


3 


1 


3 


c n 
6.9 


n n/^o 
0.068 


code 


VO 


1 1 
12 


i 
1 


1 1 
12 


o 

0.6 


n 1 no 
0.1 Uo 


op 




V20 


1 i 
1 1 


1 


1 1 
1 1 


n o 
9.2 


n i no 
0.1U8 


addcode 


V / 


io 


i 
1 


36 


9.2 


n nn 
0.0/2 


const 




V2 / 


1 n 
10 


1 


1 n 
ID 


1 n n 
10.9 


n i no 
0.108 


addcode 


. ,o 
V8 


1 
1 


i 
1 


1 
1 


0.6 


0. 1 12 


const 




V28 


10 


' 


CO 

JO 


C H 
J. / 


n non 
O.OOO 


Branch 


V9 


n 
9 


i 
1 


9 


c o 
5.2 


n ivn 
0.092 


op 




V29 


1 o 
10 


1 


1 A 

14 


C *7 
J. / 


n nno 
0.092 


code 


vlU 


i /i 
14 


2 


1 A 

14 


n t 
9.2 


n 1 q^; 
0.130 


op 




V3U 


CO 

JO 


1 


CO 

Jo 


C *7 
J. / 


n n/i/i 
0.064 


code 


..11 

vll 


i /i 
14 


2 


1 A 

14 


0.3 


n non 
0.000 


op 




v31 


1 A 

14 




1 A 

14 


1 n n 
10.9 


n nno 
0.0U8 


addcode 


vl2 


70 


1 


48 


9.2 


0.164 


op 




v32 


2 




2 


10.9 


0.004 


addcode 


vl3 


4 


1 


4 


9.2 


0.080 


const 




v34 


77 




77 


8.6 


0.100 


op 


vl4 


50 


1 


50 


8.1 


0.028 


const 




v35 


76 




58 


5.7 


0.060 


code 


vl5 


10 


3 


10 


7.5 


0.104 


const 




v36 


126 




126 


2.9 


0.024 


op 


vl6 


70 


1 


70 


9.2 


0.104 


init 




v37 


93 




93 


8.6 


0.040 


index 


vl7 


35 


1 


35 


9.2 


0.096 


init 




v39 


3 




3 


6.9 


0.088 


op 


vl8 


29 


1 


29 


6.9 


0.124 


init 




v40 


126 


2 


126 


6.3 


0.088 


assign 


vl9 


19 


1 


19 


9.2 


0.112 


init 




v41 


20 


1 


20 


8.6 


0.120 


assign 


v20 


18 


1 


18 


9.2 


0.120 


op 



















"RunTime" shows the run time for each run of BugAssist in 
seconds and they are negligible. The last column is the type of bug 
which is explained in Table[2] For example, the version v2 has one 
error injected and has 69 failing testcases. We collected the bug 
locations reported during these 69 runs of the tool which gave 8 
potential bug locations, which is 4.6% of the total line number's in 
the program. The exact location of the fault is identified in all the 
69 runs. 



Table 2. Type of Error 



Error Type 


Explanation for the error 


op 


Wrong operator usage 
eg: <= instead of < 


code 


Logical coding bug. 


assign 


Wrong assignment expression. 


addcode 


Error due to extra code fragments. 


const 


Wrong constant value supplied 
eg: off-by-one error. 


init 


Wrong value initialization of a variable. 


index 


Use of wrong array index. 


branch 


Error in branching due to negation of 
branching condition 



Except for a few versions like vl2, v28 and v35, BugAssist 
detected the correct bug location for all the runs. For the remaining 
ones, when we rank locations based on frequency of being reported 
as bugs, exact bug locations had a count more than half of the total 
number of runs. The runs in which exact location was not reported 
did give clues about the real bug. For example, some testcases had 
wrong constant value assignment to an array element, for which the 
tool reported the fault at places where that array is accessed rather 
than the line at which the bad assignment occured. By analyzing 
the error locations it is quite evident that the error is due to a wrong 
value to that array location. On average the number of lines to 
check for potential bug is reduced to 8% of the total code. It should 
be noted that most of the single runs of the faulty version have 
captured the exact bug location. 



The Figure 2 gives an overview of a version of teas (v2). with 
the bug at line 2, the original code is given in comment in line 3. 
The declaration and initialization of variables, functions and condi- 
tional statements that are not relevant to this bug are omitted in this 
example. The bug is injected in function Inhibit Jiiased_Climb at 
line 2 by confusing the constant values. The original code is shown 
in comments at line 3. The program needs to satisfy the safety prop- 
erty alt_sep_test() should return DOWNWARD _RA and is given as 
assertion at line 37. There was 69 failing testcases for this version, 
we ran all these error traces and the tool returned 8 potential bug 
locations which are shown underlined in Figure 2. 

There is no error reported in function Non_Crossing_Clirnb() 
because the call for that function at line 25 needs the function 
Own_Below_Threat() to be true, but that is false based on a com- 
parison on the input parameters which are made hard clauses. Now 
lets take a closer look at the reported errors. 

• The line 34 is too weak for a fix because changing the return 
value can make the assertion always true and that does not serve 
as a suitable fix. 

• In line 26 making the need_downward_RA variable true can pick 
the right value for alt^sep. This decision is made by evaluation 
of the two functions in that statement. The Own_Above_Treat( ) 
is true based on the input and it is clear that the correction needs 
to be done to the function call Nonprossing _Decend(). 

• The function NonJZrossingJ)ecend{) has a call for the actual 
faulty function at line 14. It also shows the repair could be done 
by changing the return value of this function at line 19, or where 
the wrong evaluation happens at (lines 15,16). 

• The actual bug at line 2 is reported as a potential bug location 
in all the runs. It is interesting that all the other locations were 
pointing to this line as the base cause and helps the programmer 
to make a fix at the root cause of the problem. 

6.2 Larger Examples 

To prove the scalability of our approach, and applicability in the 
presence of complex pointers and loops, we choose a bunch of 
other testcases with function calls, recursion, dynamic memory al- 
location, loops, and complex programming constructs. In the TCAS 
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Table 3. Running Bug-Assist on larger benchmark programs from Siemens testsuite. 



testcases we did not apply any trace reduction method and used the 
entire boolean representation of the program. When the program 
size and complexity increases, the error trace formula becomes 
huge. We do a preliminary investigation as proof of concept on ef- 
fectively reducing the error trace leveraging on the existing trace 
reduction techniques like program slicing (S), concolic simulation 

(C) and isolating failure-inducing input |33 | using delta debugging 

(D) . 

Table 3 shows the result of running BugAssist on 4 other pro- 
grams from the Siemens suite each with one injected fault. "Pro- 
gram" shows the name of the program from the Siemens testsuite. 
"LOC#" is the total lines of code in the program and "Proc#", the 
number of procedure calls. The kind of reduction technique is spec- 
ified in "Reduc" and "assign#" shows the size of the dynamic er- 
ror trace as the number of assignment expressions before and af- 
ter performing reduction technique. The "var#" and "ciause#" is 
the number of boolean variables and clauses in the MAX-SAT rep- 
resentation of the error trace both before and after the reduction 
step mostly in millions(m). The number of potential fault locations 
returned by the tool is given under "Fault#". The column "Time" 
shows the runtime in seconds(s) or hours(h). 

We picked a faulty version of the program and one test input that 
reveals the bug. The golden output from the non-fault program with 
this same input is given as a post condition to this faulty program. 
Trace reduction techniques are applied to the program execution 
with this input to generate a smaller trace formula and given as 
input to BugAssist. The tool reported the exact bug location in all 
programs except one (Program 2: print_token). Trace reduction 
techniques significantly reduced the resulting trace and the size of 
the MAX-SAT instance, as shown in "Before" and 'After" sizes in 
Table 3. The cardinality of the potential fault location set for each 
of these programs is very small. In all cases, the run time of the tool 
is also smaller than the human effort required to isolate the fault on 
the original trace. This shows the applicability of the approach in 
complex real world programs. 

• The error inducing input to Program totinfo was the rows and 
columns of a matrix. The bug was in the constant value of a con- 
ditional operator on checking the product of rows and columns 
after a few other operations. A simple program slicing removed 
the assignments irrelevant to the assertion being checked and 
reduced the number of assignments to 21 with run time less 
than a second. 

• Program print_token contained a recursive function 
"next_token" and the input to the program required the loops to 
be unrolled 8 times in the symbolic trace formula generation. 
This made the recursive function to have 64 instances in the 
symbolic trace and the number of assignments went up to 65 K 
without concolic execution. Using concrete execution for the 
recursive function and variables brought down the number 
of assignment statements to 239. It should be noted that the 
limitation in using a concrete execution would be to assume 
that the bug is not present in the functions and loops which are 



concretized. However, this methodology fits well in programs 
using functions from a reliable library or for functions which 
are already verified to be bug free. This program did not show 
the the bug at the exact location, which was a comparison on a 
variable which got the value from the concrete execution. This 
was because the constant propagation used by the symbolic 
trace generator abstracted away the variable since its values 
was a constant. Instead, the error was shown in the assignment 
of the variable to the constant. 

• The priority scheduler program 3 and 4, contained a large error 
inducing input which called a bunch of procedures before devi- 
ating from the golden output of the original program. The trace 
size was significantly reduced after isolating the error inducing 
input using delta debugging, but was still quite big (about 400 
and 5400 assignment operations respectively). In program 3, 
the off-by-one error on flushing the number of processes was 
detected by the presence of a single process creation (leading 
to a trace of about 400 assignments). But program 4 required 
a much larger input and more procedures to expose the failure, 
resulting in a longer trace. It took BugAssist almost 1 1 hours to 
find the exact location (excluding the time taken for input mini- 
mization using delta debugging). Each execution of MAX-SAT 
took around 30 minutes to identify one potential fault location. 

6.3 Fixing Off-By-One Errors 



Program 2 The strncpy program with Off-By-One error. 

1 #define SIZE 15 

2 void MyFunCopy (char *s) 

3 { 

4 char buf [SIZE] ; 

5 memset (buf , 0, SIZE); 

6 strncat (buf , s, SIZE); 

7 /*Last argument should be: SIZE-1 */ 

8 return; 

9 } 

/♦Standard C implementation of strncat*/ 

10 char *strncat (char *dest, const char *src, 

size_t n) 

11 { 

12 char *ret = dest; 

13 while (*dest) 

14 dest++; 

15 while (n — ) 

16 if (!(*dest++ = *src++)) 

17 return ret; 

18 *dest = 0; /*Problem cause*/ 

19 return ret ; 

20 } 



We demonstrate the repair capability of BugAssist by synthe- 
sizing fixes for Off-By-One error which are common programming 
error for users of C library routines because of their inconsistency 
with respect to whether one needs to subtract one byte or use the 
correct size. One common Off-By-One error in C library which re- 
sults in security related theart is caused by the misuse of strncat 
routine |22|. A common misconception with strncat is that the guar- 
anteed null termination will not write beyond the maximum length. 
In reality it will write a terminating null character one byte beyond 
the maximum length specified. 

The Program [2] shows an instance of the bug in the function 
MyFunCopy, which takes a string s and uses the strncat rou- 
tine to copy the contents to a string buf of length SIZE. The 
lines 10-20 shows a standard C implementation of strncat. Note 
that after copying the n characters at line 17 it writes to the n + I th 
location of the dest string at line 18. This require that the function 
MyFunCopyO should be using SIZE — 1 as the last argument 
to function strncat. 

We ran BugAssist on this function turning on the check for ac- 
cesses within array bounds. It located the line 6 as a potential bug 
location in the code. We have taken the assumption that the library 
functions cannot be modified and in the pMAX-SAT problem for- 
mulation we make constraints arising out of library functions hard 
clauses. This location is already marked during preprocessing as 
a statement with a constant; the BugAssist now tries to fix it by 
changing the value to SIZE — 1 and SIZE + 1 as explained 
in the Algorifhm[2] This requires turning off constant propagation 
while converting the program in to boolean formula and collecting 
the literals in the CNF corresponding to each constant. Then we 
create two SAT instances with these new constant values and give 
it to MiniS AT solver to check property violations. In this example 
it came up with a success on the value SIZE — 1 and is provided 
as a fix for the fault. 

6.4 Finding Faulty Loop Iteration 



Program 3 The nearest integer square root function with bug at 



line 12 


1 int 


squareroot () 


2 { 




3 


int val = 50 ; 


4 


int i =1; 


5 


int v =0; 


6 


int res =0; 


7 


while (v < val) 


8 


{ 


9 


v = v + 2*i +1; 


10 




11 


} 


12 


res = i; 


13 


/* res = i - 1; */ 


14 


assert ( (res*res <= val) kk 




((res+l)*(res+l) 


15 


return res ; 



} 



The program [3] contains a function to find the nearest integer 
square root of a value. The post condition specified as assertion 
requires that the res should be the closest square root for val. The 
bug locations reported by BugAssist are underlined. The correct 
code is given as comment in line 13. Even though the actual bug 
is not in the loop body it requires a through analysis of the loop to 
conclude the right fix at line 12. We gave the unwinding limit 50 to 



CBMC and the BugAssist reports the 8* iteration of the loop as 
the first occurrence of line 10 fault. 

7. Scalability and Limitations 

The fault localization depends on the underlying boolean transform 
of the program to clauses. Therefore the code omission faults can- 
not be detected due to the non existance of those clauses, instead it 
tries to fix expressions with in the current program to validate the 
asserted property. In most of the cases a single error trace was suf- 
ficient to locate the exact error location and that shows the speed 
up of this method compared to the existing fault localization ap- 
proaches. Each of the potential error locations are the unsatisfied 
clauses during each iteration of the MAX-SAT solver. Using an 
incremental SAT approach for each of these iterations can consid- 
erably bring down the running time of the tool. Moreover, there is 
a growing interest in extracting the unsatisfiable cores | 20| which 
can further aid this approach. 

As shown in the experimental results, without applying any 
trace reduction technique this method may blow up the state space 
and may not be suitable for programs with complex calls or enor- 
mous lines of code. However, the tool would be handy in an In- 
tegrated Development Environment(IDE) where the programmer is 
interested in debugging the function under development and can ab- 
stract away the rest of the program as input output relationship. This 
methodology can provide online hints for the programmer assisting 
in code development phase and is the motivation in developing the 
Eclipse plugin for the tool. Any error trace reduction method can 
also be applied orthogonally to this approach to bring down the 
trace. 

8. Conclusions 

Program analysis based on Boolean satisfiability has been ex- 
tremely successful in detecting subtle errors in large software pro- 
grams 1 4 6 31]. We show that techniques based on Boolean MAX- 
SAT can be similarly effective in localizing program errors (as well 
as in identifying potential fixes). 

Our technique can leverage engineering advances in modern 
SAT and MAX-SAT solvers, and as our experiments demonstrate, 
provide a precise and scalable solution to the error localization 
problem. While we have described error localization at the line- 
number (or program statement) level, our reduction to pMAX-SAT 
is general, and can be used at different levels of granularity. For 
example, to localize bugs at the module level, we can group clauses 
coming from the same module in the pMAX-SAT instance. 

To improve the usability of our tool, we have built an Eclipse 
plugin to help the programmer to find bug locations during the 
development process. It marks the potential bugs in the code under 
development and assist in analyzing the right fix. The tool also 
marks the repair capabilities at a line and the user can also ask for 
automated repair like Off-By-One fix as discussed in this paper. 

In future we would like to explore the various automated bug 
fixing capabilities by analyzing the bug locations. This requires 
predicting the type of error which has a maximum probability 
in a particular expression. It would be interesting to mine the 
software repositories for bug patterns and building a model for 
expression specific error types based on the repository history and 
use it for guiding BugAssist for an appropriate repair strategy. 
Another direction is to provide constructive suggestions to the 
programmer in fixing a bug. For example, Suppose the BugAssist 
comes up with an error statement which has a constant; showing 
the lower and upper bound of the values for that constant which 
holds the given properties help the programmer to provide a robust 
fix. 
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